Oracle 11g Dataguard 配置，维护与详解 (ADG)

一、前言：   

    本手册主要记录如何配置，还介绍了配置原因，以及注意要点，已经主备切换，以及故障转移等重要操作步骤，我希望这个文章可以作为进行dataguard配置的一个参考手册。

二、前提

1.主库是归档模式：      

    如果我们不清楚为什么是归档模式，那我们就应该也不会清楚dataguard是用来做什么的。透过很多修饰的官方语言，我们需要明确DG（dataguard简称，后同）实际上的作用就是用来高可用。而实现原理就是从主库获取数据到从库，在主库发生异常的时候，从库接管主库，完成身份的变化。可以一个主库，最多9个从库。同时分为逻辑standby和物理standby这里我们讨论的是物理standby.   一旦创建并配置成 standby 后，dg 负责传输 primary数据库 redo data 到 standby 数据库，standby 数据库通过应用接收到的 redo data 保持与 primary 数据库的事务一致。这下清楚了吧，需要保证主从库一致，需要传输archive log和redo log到从库，如果不是归档模式无法保证主从库的数据一致。本次操作的从库是主库的克隆（在主库导入脚本之前，进行的操作）

步骤：

在主库上创建归档目录

$ mkdir /oradata/dg

(以Oracle身份进行的创建，若以root身份进行创建需要，修改归档目录的属主属组，让oracle:oinstall，拥有访问的权限)

$sqlplus / as sysdba

$startup mount

$alter system set log_archive_Dest=’/oradata/dg’;

$alter database archivelog

$archive log list;

(此时若主库的归档设置成功，则将出现automatic archival enabled;archive destination /oradata/dg 提示信息)

2.从库只需要安装数据库软件，数据从主库传输后完成。

 备注：（若采用主库的克隆，则无需关心该步骤）

备注：所谓的ADG,只不过就是在备库，应用redo log 的同事，避免资源的浪费，（10g之前的dg备库必须处于Mount状态，才可以接收应用redo log）,11g增加的ＡＤＧ的功能支持，备库处于open状态（默认为read only模式），同时可以接收并应用redo log

4.主从库硬件最好一致。oracle数据库版本需要一致。  

内存检查项：

 #grep MemTotal /proc/meminfo      

交换分区检查项：如果内存在1-2G,swap是1.5倍；2-16G,1倍；超过16G，设置为16G即可。     

# grep SwapTotal /proc/meminfo    

查看共享内存大小：    

 # df -h /dev/shm

  查看系统处理器架构，与oracle安装包一致     

# uname -m

  空间空间 /tmp必须大于1G     

# df -h /tmp

备注：本次操作过程中对于该目录并未有严格的要求

5.配置环境数据库用户必须有sysdba权限 6.后面的环境：

 主库 10.1.41.81 数据库实例名：ctdb db_unique_name:ctdb  

 从库 10.8.41.81 数据库实例名：ctdb db_unique_name:ctdbdg

三、配置 1.判断DG是否已经安装

  sql>select * from v$option where parameter = 'Oracle Data Guard';   

如果是true表示已经安装可以配置，否则需要安装相应组件。

2.设置主库为强制记录日志  

默认情况下数据库操作会记录redo log，但是在一些特定的情况下可以使用  nologging来不生成redo信息  

表的批量INSERT（通过/*+APPEND */提示使用“直接路径插入“。或采用SQL*Loader直接路径加载）。表数据不生成redo，但是 所有索引修改会生成redo，但是所有索引修改会生成redo（尽管表不生成日志，但这个表上的索引却会生成redo！）。  

LOB操作（对大对象的更新不必生成日志）。  

通过CREATE TABLE AS SELECT创建表  

各种ALTER TABLE操作，如MOVE和SPLIT  

在一些表迁移和表空间迁移中，可以使用alter table a nologging;或者alter tablespace snk nologging;在操作完成后再修改回logging状态。   这里需要多说一句，如果你使用nologging导入大批量数据，以后对这些数据的修改会在redo或者archive log中，但是基准的数据是没有的，所以一旦介质损坏是无法完全恢复的，必须在使用nologging完成切换回logging后，做一次全备或者0级备份。

  主库步骤如下：

  强制记录日志：

   sql>alter database force logging;    

检查状态(YES为强制)：

   sql>select name,force_logging from v$database;  

如果需要在主库添加或者删除数据文件时，这些文件也会在备库添加或删除，使用如下：       sql>alter system set standby_file_management='AUTO';       默认此参数是manual手工方式

sql>show parameter standby  

 3.创建standby log files(备用日志文件）      

从库使用standby log files来保存从主库接收到的重做日志。既然主要是从库在使用，那为什么需要在主库上也建立standby log files?原因主要由两个：一是主库可能转换为备库，而备库是需要有standby log files的 二是如果主库建立了standby log files那备库会自动建立。    

建立standby如要注意以下几点：   

 standby log files的大小和redo log files一样,查询redo log files文件大小（默认50M,3个）：

Sql>select group#,bytes/1024/1024 as M from v$log     

  一般而言， standbyredo 日志文件组数要比 primary 数据库的 online redo 日志文件组数至少多一个。推荐 standbyredo 日志组数量基于 primary 数据库的线程数(这里的线程数可以理解为 rac 结构中的 rac节点数)。    有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数

假设现在节点是1个，则=(3+1)*1=4   如果是双节点,则=(3+1)*2=8   这里我们创建4个standby logfile:    另：不建议组号group# 紧挨着redo，因为后续redo有可能调整，这里我们从建立从11到14的standby logfile

    sql> alter database add standby logfile group  11 '/oradata/dg/standby11.log' size 50M;

    sql> alter database add standby logfile group  12 '/oradata/dg/standby12.log' size 50M;

    sql> alter database add standby logfile group  13 '/oradata/dg/standby13.log' size 50M;

   sql> alter database add standby logfile group  14 '/oradata/dg/standby14.log' size 50M;

 4.密码文件和控制文件的创建传输   

一般数据库默认就有密码文件，存放在$ORACLE_HOME/dbs/orapwSID  这里为orapwctdb,如果没有,执行如下操作即可

 sql>orapwd file=$ORACLE_HOME/dbs/orapwctdb password=oracle     

检查REMOTE_LOGIN_PASSWORDFILE值是否为 EXCLUSIVE        

sql>show parameter REMOTE_LOGIN_PASSWORDFILE      

如果值不是EXCLUSIVE，则：

 Sql>alter system set remote_login_passwordfile=exclusive scope=spfile;   

密码文件需要scp到从库        

# scp orapwctdb [email protected]:$ORACLE_HOME/dbs 提示输入yes      

控制文件：        

11g的控制文件一共两份:$ORACLE_BASE/oradata/ctdb/control01.ctl，另一份在$ORACLE_BASE/flash_recovery_area/ctdb/control02.ctl

 备注：该处的控制文件，我只在$ORACLE_BASE/oradata/ctdb下面找到了两个控制文件，其他地方并未找到

 生成standby控制文件： 

 sql>shutdown immediate

 sql>startup mount

 sql>alter database create standby controlfile as '/tmp/standby_control01.ctl';

 sql>startup open;  然后在备库建立对应的目录,并授权  $mkdir ctdb

备注：由于我的备库是克隆而来，所以并未执行上述操作

$scp /tmp/standby_control01.ctl [email protected]:/$ORACLE_BASE/oradata/ctdb

$scp /tmp/standby_control01.ctl [email protected]:/app/oracle/fast_recovery_area/VCDB/controlfile

备注：第二步的复制操作，我执行了，但并不清楚有什么实质性的意义

5.db_name和db_unique_name    

     默认db_name和db_unique_name和实例名是一致的，这里是ctdb需要注意在DG中主库和从库的db_unique_name是不能一致的，需要区分开的。这里我们设置主库的db_unique_name为ctdb，从库为ctdbdg   sql>show parameter db_unique_name   设置：

  Sql>alter system set db_unique_name=ctdb scope=spfile;   

备注：注意虽然默认db_unique_name和db_name是一致的，但是需要显式设置，否则在spfile中没有此参数     

6.闪回数据库：     

强烈建议开启数据库闪回功能。闪回允许你将数据库还原到以前的某一时间点。当发生故障转移时，这个功能非常有用，它能让你将老的主库闪回到故障前，然后将其转换为备库。如果没有启用闪回功能，你就必须重建备库，意味着要再复制一次数据文件。除了这个好处，闪回还能在某些情况下让你避免从备份恢复数据。   

快速恢复区(Flash/Fast Recovery Area)，默认是配置的,但是需要确认这个区域的磁盘够大，至少300G以上（默认3G）   

sql>show parameter db_recovery_file_dest   可以修改位置：

sql>alter system set db_recovery_file_dest='新路径';     更改大小：

sql>alter system set db_recovery_file_dest_size=400G;

查看是否启用，默认是不开启的        

sql>select flashback_on from v$database;        开启：

sql>alter database flashback on;       

如果你碰到 ORA-01153 报错，那一定是在备库进行此操作。你需要先取消重做日志应用，启用闪回日志，然后重新启用日志应用。在主库启用闪回日志，不会同步备库也启用。你必须手动在主库和备库上均启用闪回日志。如果不启用闪回日志，当出现故障转移时，你将需要完全重新开始创建一个备库。

备注：本次操作中并未使用闪回区，因为我的服务器上没这么大的空间，可以使用，那也就意味着，如果出现failover的现象是，只能对原来主库进行回复之后，只能重新建立AＤＧ关系

7.SQL*NET设置      

配置主库的监听   虽然可以通过netca来进行配置，但是除了这个默认的外，我们还需要一个静态注册SID_LIST_LISTENER，如果没有此从参数而且dataguard启动顺序不正确，主库会报PING[ARC1]:Heartbeat failed to connect to standby'***'.Error is 12514导致归档无法完成, 配置如下:

SID_LIST_LISTENER=

     (SID_LIST =

  (SID_DESC =

      (GLOBAL_DBNAME = ctdb)

      (ORACLE_HOME = /app/oracle/product/11.0.4/dbhome_1)

      (SID_NAME = ctdb)

  )

     )

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = CTAuditdb)(PORT = 1521))

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

    )

  )

ADR_BASE_LISTENER = /app/oracle

#vi $ORACLE_HOME/network/admin/listener.ora 加入上面的内容

配置tnsnames         

#vi $ORACLE_HOME/network/admin/tnsnames.ora

# tnsnames.ora Network Configuration File: /app/oracle/product/11.0.4/dbhome_1/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

CTDBDG =

   (DESCRIPTION =

     (ADDRESS_LIST =

       (ADDRESS = (PROTOCOL = TCP)(HOST = 10.8.41.82)(PORT = 1521))

     )

     (CONNECT_DATA =

       (SERVICE_NAME = CTDBDG)

     )

   )

CTDB =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.41.82)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = CTDB)

    )

  )

传输到备库并修改listener.ora和tnsnames.ora

scp $ORACLE_HOME/network/admin/listener.ora [email protected]:$ORACLE_HOME/network/admin/

scp $ORACLE_HOME/network/admin/tnsnames.ora [email protected]:$ORACLE_HOME/network/admin/

--listener.ora:

  SID_LIST_LISTENER=

     (SID_LIST =

  (SID_DESC =

      (GLOBAL_DBNAME = ctdbdg)

      (ORACLE_HOME = /app/oracle/product/11.0.4/dbhome_1)

      (SID_NAME = ctdb)

  )

     )

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = b_CTAuditdb)(PORT = 1521))

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

    )

  )

ADR_BASE_LISTENER = /app/oracle    tnsnames.ora:不需要修改

  8.重做日志传输配置   

配置归档日志位置：   查询已经设置的归档路径

 sql>archive log list或者show parameter log_archive_dest_1

 sql> alter system set log_archive_dest_1='LOCATION=/oradata/dg  valid_for=(all_logfiles,primary_role) db_unique_name=ctdb' scope=spfile;  

 还可以使用快速恢复区作为归档目录，LOCATION=use_db_recovery_file_dest,官方文档里说使用 valid_for=(online_logfiles, all_roles)，这将导致备库无法归档备用日志文件，因为它们不是在线日志。但如果使用 all_logfiles 选项，主备库将都能归档在线以及备用日志。如果你想在备库进行备份，并同时备份归档日志的话，必须使用 all_logfiles。　

备注：执行该操作之前，需要执行如下操作,否则对主库的归档路径的设置，将会报错

 sql>alter system set log_archive_dest=’’;    

配置重做日志到备份库：

sql>alter system set  log_archive_dest_2='SERVICE=ctdbdg lgwr sync valid_for=(online_logfile,primary_role) db_unique_name=ctdbdg ' scope=spfile;

要注意STANDBY_ARCHIVE_DEST 参数不需要，已经被官方弃用。设置此参数后启动数据库，只会报 ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance 错。

 9.配置FAL_SERVER    

 这个参数指定当日志传输出现问题时，备库到哪里去找缺少的归档日志。它用在备库接收的到的重做日志间有缺口的时候。这种情况会发生在日志传输出现中断时，比如你需要对备库进行维护操作。在备库维护期间，没有日志传输过来，这时缺口就出现了。 设置了这个参数，备库就会主动去寻找那些缺少的日志，并要求主库进行传输。你是主库,就填写:fal_server=从库,从库上就反过来:fal_server=主库 注意:FAL_CLIENT在11g中已经废弃，虽然可以配置但是已经不起作用了。

sql>alter system set FAL_SERVER='ctdbdg';

10.Data Guard 配置里的另外一个库的名字     

sql> alter system set log_archive_config = 'dg_config=(ctdb,ctdbdg)';

备注：以上的办法是我们采用alter system的方式在线修改，还有一种比较方便的办法（但是容易出错，所以方便和安全什么时候都不可兼得）   

sql>create pfile from spfile;    

# 手工修改pfile    

sql>create spfile from pfile;   

然后用pfile生成spfile 同时传输pfile到从库修改后生成spfile注意手工增加：   

*.log_archive_dest_state_1=enable   

*.log_archive_dest_state_2=enable   

#vi initorcl.ora

ctdb.__db_cache_size=1862270976

ctdb.__java_pool_size=16777216

ctdb.__large_pool_size=100663296

ctdb.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

ctdb.__pga_aggregate_target=838860800

ctdb.__sga_target=2516582400

ctdb.__shared_io_pool_size=0

ctdb.__shared_pool_size=503316480

ctdb.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/ctdb/adump'

*.audit_trail='db'

*.compatible='11.2.0.4.0'

*.control_files='/app/oracle/oradata/ctdb/control01.ctl','/app/oracle/oradata/ctdb/control02.ctl'

*.db_block_size=8192

*.db_domain=''

*.db_name='ctdb'

*.db_unique_name='CTDB'

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=ctdbXDB)'

*.fal_server='ctdbdg'

*.log_archive_config='dg_config=(ctdb,ctdbdg)'

*.log_archive_dest=''

*.log_archive_dest_1='LOCATION=/oradata/dg valid_for=(all_logfiles,primary_role) db_unique_name=ctdb'

*.log_archive_dest_2='SERVICE=ctdbdg lgwr sync valid_for=(online_logfile,primary_role) db_unique_name=ctdbdg '

*.log_archive_dest_state_1=enable

*.log_archive_dest_state_2=enable

*.open_cursors=300

*.pga_aggregate_target=838860800

*.processes=150

*.remote_login_passwordfile='EXCLUSIVE'

*.sga_target=2516582400

*.standby_file_management='AUTO'

*.undo_tablespace='UNDOTBS1'  

 然后sql>create spfile from pfile;   

11.传输主库数据到备库        

步骤1：

scp -l 8192 -rp  /oradata/ 　[email protected]:/oradata 

scp -l 8192 -rp $ORACLE_BASE/ oradata/ctdb/       [email protected]:$ORACLE_ BASE/oradata/ctdb

-l是limit限制，这样最大是8192/8=1M速度，是为了解决stalled问题, -rp 循环子目录文件

备注：在第二步的操作中注意，首先在备库上把相应目录下的,控制文件进行备库，以免被主库的控制文件覆盖

建立spfile中需要的目录       

如:/opt/oracle/admin/orcl/adump dpdump pfile

备注：本次操作中不需要第二步的操作

12.启用物理备用数据库       

sql>startup nomount       

sql>alter database mount standby database;       

启动 redo 应用   　 

sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

备注：不需要执行上述步骤      

启动实时应用  

 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;        这个命令指示备库开始使用备用日志文件进行恢复。它也告诉备库命令完成后回到命令行界面

  SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;   　 此时只是暂时 redo 应用，并不是停止 Standby 数据库，standby 仍会保持接收只不过不会再应用接收到的归档，直到你再次启动 redo 应用为止

备注：该步骤当需要切换备库的模式时可以使用，比如说从管理模式到，只读模式的转变 

停止standby         

正常情况下，首先     

 sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;    

然后再

sql>shutdown immediate(当然也可以直接shutdown immediate)

  备用服务器的管理模式与只读模式       

     1> 启动到管理模式

      sql>shutdown immediate;

      sql>startup nomount;

      sql>alter database mount standby database;

      sql>alter database recover managed standby database disconnect from session;

   2> 启动到只读方式    

      sql>shutdown immediate;

      sql>startup nomount;

      sql>alter database mount standby database;

      sql>alter database open read only;

   3> 如果在管理恢复模式下到只读模式

      sql>alter system recover managed standby database cancel;

      sql> alter database open read only;

      这个时候，可以给数据库增加临时数据文件（这个在热备份的时候是没有备份过来的）       如alter tablespace temp add tempfile '/u02/oradata/test/temp01.dbf' size 100M;

备注：并未用到该步骤       

  4> 从只读方式到管理恢复方式       

    sql> alter system recover managed standby database disconnect from session;

在主数据库上设置DataGuard的保护模式.把主数据库启动到mount状态设置好DataGuard的保护模式.

　　sql>alter system set log_archive_dest_state_2=ENABLE scope=both;

　　sql>shutdown immediate;

　　sql>startup mount;

　　sql>alter database set standby database to maximize availability;

     sql>alter database open;  

应用物理备库的几点监控      

 如果上面出了问题或者我们不知道成功了没有，可以用下面的方法检测       

   1> 确认主备库里的归档目的地配置都是有效的         

   sql>select DEST_ID, STATUS, DESTINATION, ERROR from V$ARCHIVE_DEST where DEST_ID 确认重做日志是否真的被应用了，在主库执行         

   sql>select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG where name = 'JED2' order by FIRST_TIME;       如果归档和日志应用均正常，APPLIED 和 ARCHIVED 列都应该是 YES。(如果没有应用redo，applied应该是NO)很多教程里都让这个查询以 SEQUENCE# 列排序，但我不推荐。如果以 SEQUENCE# 列排序，当你做了一次故障转移后，序列号会再从1开始，这时使用这个查询，你将不能在结果最后看到最新的记录。我曾经很奇怪为什么查不到新记录，其实是因为新记录不是出现在最后,我没看到。所以，这个查询都是以 FIRST_TIME 列排序.  

   3> 主库上检查是否有重做日志缺口         

   如果你发现日志没有被应用，那可能是重做日志有了缺口，这种情况下备库无法进行日志应用。但如果你的 FAL_SERVER 参数设置正确，这应该不会有问题         

    sql>select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;   如果一切正常，应该返回 VALID 和 NO GAP .切记启用redo应用才能显示No GAP  

   4> 在主备库上执行以下查询查看数据库状态         

    sql>select * from V$DATAGUARD_STATUS order by TIMESTAMP;        

   5> 检查是否成功：         

    主库上查看日志传送情况：        

　　 sql>select dest_name,status,error from v$archive_dest;         应该log_archive_dest_1和2状态应该是valid    

    切换几次日志：         sql>alter system switch logfile;            查看日志序号：         sql>select sequence# from v$archived_log;             备库验证：         sql>select sequence#,applied from v$archived_log;     

 13.dataguard启动关闭顺序       

监听    先启从库再起主库        #lsnrctl start          

启动    

先启从库：     

 sql>startup nomount      

sql>alter database mount standby database;   

sql>alter database recover managed standby database using current logfile disconnect from session;    　

 再启主库   

sql>startup       

  关闭：和开启正好相反           

先关主库：       

sql>shutdown immediate       

再关从库：       

sql>alter database recover managed standby database cancel;      

sql>shutdown immediate;

  操作步骤如下：

  查看主备数据库的状态

 sql>select inst_id,database_role,open_mode from gv$database;

  主库检查switchover 状态如果是to standby或者sessions active表明可以进行切换，sessions active意味着主备库有活动sessions关联，在switchover前需要将这些sessions关闭(with session shutdown)。

sql>select switchover_status from v$database;

 主库切换：

 sql>alter database commit to switchover to primary with session shutdown;

备库切换：

sql> alter database commit to switchover to standby with session shutdown ;

原主库mount到standby状态

sql>shutdown abort

sql>startup mount

原主库停止远程归档路径：

sql>alter system set log_archive_dest_state_2=defer;

原主库启用实时查询

sql>alter database revocer managed standby database using current logfile disconnect;

sql>alter database recover managed standby database cancel

sql>alter database open

sql>alter database recover managed standby database using current logfile disconnect

这时新主库状态为to standby,在新备库recovery前，其状态为FAILED DESTINATION，而备库状态为RECOVERY NEEDED。

sql>select switchover_status from v$database;

主库切换几次日志，验证主备库的日志同步情况

主库：

sql>alter system switch logfile

备库：

sql> select sequence#,archived,applied from v$archived_log;

    Failover的状况有很多，也取决于当时主库的损毁状况以及，当时数据库的搭建方式，这里起其他的方面不再进行演示以及描述如何进行修复，此处仅仅演示了最简单粗暴的一种情形：主库异常宕机，且数据库所在的服务器也异常损毁，该处我们所做的，只针对备库

备库操作：

查询备库，是否有gap,若有将对应的归档文件copy至备库（前提是主库的归档所在的目录，存在备份，或者不是本地存储，已经完整保存下来了）

sql>select thread#,low_sequence#,hige_sequence# from v$archive_gap;

#若存在gap，copy之后，注册

sql>alter database register physical logfile ‘/oradata/dg/1_38_925143214.dbf’ 

取消和停止应用

sql> alter database recover managed standby database cancel;

sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

#如果主库和备库之间的网络中断了，那么备库的RFS进程就会等待网络的连接，直到TCP超时。此时需要加上force关键字

sql>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH force;

此时standby状态

sql> select open_mode, switchover_status from v$database;

进行切换

sql> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

重启数据库

 重启新主库，对外提供服务

sql> shutdown immediate;

ORA-01109: database not open

Database dismounted.

sql> startup

ORACLE instance started.

Total System Global Area  835104768 bytes

Fixed Size                  2257840 bytes

Variable Size             746589264 bytes

Database Buffers           79691776 bytes

Redo Buffers                6565888 bytes

Database mounted.

Database opened.

Failover后的还原

    由于Failover后主备关系消失，是迫不得已的操作，当主库fix完后，需要重启还原，如果开启了flashback功能，则flashback至Failover时的SCN，再重新应用备库日志。或者重新创建standby，然后再switchover。

使用闪回还原主库：

sql> SELECT to_char(STANDBY_BECAME_PRIMARY_SCN) from V$DATABASE;

sql> SHUTDOWN IMMEDIATE;

sql> STARTUP MOUNT;

sql> FLASHBACK DATABASE TO SCN &standby_became_primary_scn;

#将原主库转换成物理备库，并启动日志应用进程

sql> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

sql> SHUTDOWN IMMEDIATE;

sql> STARTUP MOUNT;

sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

备注：本次操作并未启用闪回功能，所以只能重新新建主库，然后才依据上面的ADG搭建的步骤重建主备关系